Although computers were once isolated and had minimal or little interaction with other computers, computers now interact with a wide variety of other computers through Local Area Networks (LANs), Wide Area Networks (WANs), dial-up connections, and the like. With the wide-spread growth of the Internet, connectivity between computers has become more important and has opened up many new applications and technologies. The growth of large-scale networks, and the wide-spread availability of low-cost personal computers, has fundamentally changed the way that many people work, interact, communicate, and play.
One increasing popular form of networking may generally be referred to as remote presentation systems, which can use protocols such as Remote Desktop Protocol (RDP), Independent Computing Architecture (ICA), and others to share a desktop and other applications with a remote client. Such computing systems typically transmit the keyboard presses and mouse clicks or selections from a client computing device to a server computing device, relaying the screen updates back in the other direction over a communications network (e.g., the INTERNET™). As such, the user has the experience as if their machine is operating as part of a LAN, when in reality the client is only sent screenshots, or frames, of the applications as they appear on the server side.
Where many remote presentation sessions are to be served, a server farm configuration may be used. In a server farm, a plurality of remote presentation session servers may host remote presentation sessions. Each server may host one or more virtual machines (VMs), each VM configured to engage in a remote presentation session with a client. Such servers are frequently referred to as “hosts” when hosting one or more VMs.
There are problems with a server farm. Servers may need to be periodically taken offline for maintenance activities (like applying patches), and this disrupts any remote presentation sessions active on the server. Further, electricity consumption (frequently a significant issue for server farms) may be difficult to minimize. Where a single server has the processing resources to execute each remote presentation session, but the remote presentation sessions are active across each of the servers of the server farm, each of those servers is active and consuming power, instead of a single server being active and consuming power.
There do exist techniques for balancing loads—the amount of work that an individual computer must perform (given that, when a process is referred to as having a load, it may be thought of as the process's contribution to the load of the computer upon which it executes)—across the servers of a server farm. However, these techniques do not account for remote presentation sessions that may be executing on the server, so are sub-optimal in the remote presentation session case. For instance, a VM hosting a remote presentation session may have only disconnected remote presentation sessions (a disconnected session may be distinguished from a logged off session in that a disconnected session may still have activity associated with it, such as a batch process being executed, even though an active remote presentation session is not occurring with a client; further where the client locks the remote presentation session similar to locking a desktop computer, the session is set to disconnected rather than logged off), and could be put to sleep, and present techniques would not identify this, and not be able to achieve the load balancing or electricity savings that would go with such identification and corresponding processing.